1. Field of the Invention
The present invention generally relates to the storage of medical data and in particular to providing medical imaging capabilities through a database management system.
2. Brief Description of Related Developments
Digital Imaging and Communications in Medicine (“DICOM”) is the dominant standard for radiology imaging and communication. DICOM standardizes the data format and transfer protocol for data such as for example, images, waveforms, workflow messages and diagnostic reports. It is used in many fields of medicine, such as for example, radiology, cardiology and dentistry. The DICOM standard encompasses a large number of medical imaging modalities, such as for example computed tomography, magnetic resonance, ultrasound, positron emission tomography and digital radiography.
A DICOM object can store medical images, waveforms and diagnostic reports. A key concept of DICOM is to store metadata (attributes) along with image or waveform content. The metadata augments the image or waveform content with ownership, organization, imaging condition, layout, and workflow information. There is frequently a need to search DICOM images by this metadata or share the metadata with a popular web formatting specification such as extensible Markup Language (“XML”). In addition, there is also a need to share the image content with applications outside of a DICOM image repository (e.g. PACS).
DICOM was initiated by the American College of Radiology (ACR) to enhance the connectivity of radiological devices. Before DICOM became a widely adopted standard, each manufacturer had its own proprietary image format and communication protocol. It was almost impossible to produce third-party software to manage and/or study medical data. It was also impossible to connect devices from different manufacturers. In 1985, ACR and the National Electrical Manufacturers Association (NEMA) jointly published a medical imaging and communications standard, which was named the ACR-NEMA standard, to address this problem. Later in 1993, the standard went through major revisions and was renamed to DICOM (version 3.0). Since then, DICOM has dominated the field of radiology imaging and all major manufacturers conform to this standard. Today, any software component can take DICOM data from any manufacturer and manage the data with a uniform interface.
Like other standards, the DICOM standard is mostly developed by volunteers. Working groups formed by domain experts propose additions and changes to the existing standards and the changes are approved by a balloting process. Typically, NEMA publishes a new version of the standard each year on its web site [DICOMWEB] and the document is freely available for worldwide download.
The DICOM standard has two major areas of focuses: the data format and the communication/message protocol to exchange DICOM objects. The first part, the data format, is defined using object-oriented programming principles. Images and waveforms captured by an imaging device are represented as objects (information objects in DICOM terminology). Services (operations) such as “get” “find” and “store” may be defined on these objects. The services and the information objects are combined into service object pairs (SOPs). To send an object across the network or to encode the content of a DICOM object into a file, DICOM defines different types of transfer syntax (binary encoding rules). Transfer syntax specifies the mapping of a DICOM object hierarchy into a binary stream. The binary content can be stored on physical media such as tapes, CDs or floppy disks, and organized using the DICOM directory hierarchy. It can also be exchanged over a network with the DICOM communication protocol. The DICOM communication protocol covers the upper layers (application, presentation and session layer) of the OSI seven layer model (The DICOM communication protocol is typically implemented on top of TCP/IP). Recently, the DICOM standard introduces web access to DICOM objects (WADO), which covers HTTP access to a DICOM object storage. interMedia DICOM features primarily deal with the data format aspect of the DICOM standard.
Traditionally, medical information and data, such as for example DICOM objects, are stored in a (network) file system provided by an operating system. With the recent explosive growth in both the number and size of medical images, there has been an increasing need to manage DICOM objects with a database. When compared to the flat file system, a database offers better security, scalability and manageability. Database features such as backup, disaster recovery, and logical standby are also critical to medical applications. Objects managed in a database can be indexed to improve the efficiency of retrieval with Structured Query Language (SQL). Most modern databases are integrated with mid-tier applications such as a web server or an application server to facilitate the cross enterprise sharing of the data content.
However, a traditional database management system does not recognize medical data and information such as for example, DICOM objects natively. One cannot index DICOM objects or search them by their attributes. XML is widely used in metadata management applications. XML helps to reduce software development costs because of the wide range of tools available to create, edit, display, search and transform an XML document. XML is also easier to document and implement as well as integrate with other applications, such as for example HL7 V3 messaging and bioinformatics applications.
Previous attempts to map XML to DICOM have involved message exchange. The prior solutions provide a strong type of XML schema definition to rigorously constrain a DICOM information object. The result is a large number of complex XML schemas. It is very convenient to exchange an XML representation of a DICOM object and an XML document conforming to the XML schema definition will map to a conformant DICOM object. Due to the complexity of this type of XML mapping, it is inefficient to store/query/index their representation of metadata in a database management system.
It would therefore be advantageous to be able to define an XML representation of the metadata contained in medical data and images, such as DICOM objects, to facilitate the integration of medical data and images with database management systems (“DBMS”).
To help reviewers better understand the rest of this document, some DICOM terminology is described below. Normative definitions can be found from [DICOM2004].
Standard attributes are the set of attributes defined by the DICOM standard committee, and are published in DICOM standard part 6. A standard attribute can be modified or deprecated by the standard committee at a later date. The number of standard attributes grows each year as the DICOM standard expands to new areas.
Private attributes are attributes defined by an organization and encoded in a DICOM object according to private attribute encoding rules. A private attribute can add modality-specific, manufacturer-specific or site-specific information to a DICOM object. Private attributes are not administered by the DICOM standard and are generally not known or used by any organization other than the one defining them.
Value representation is the DICOM standard's term for data type. The DICOM standard defines the following standard data types in part 5 of the standard: AE, AS, AT, CS, DA, DS, DT, FL, FD, IS, LO, LT, OB, OF, OW, PN, SH, SL, SQ, SS, ST, TM, UL, UN, US and UT.
Value multiplicity specifies how many times the value an attribute may repeat. It is part of the standard attribute specification (Part 6 of the DICOM standard).
An information object is an object-oriented representation of a real world entity in DICOM.
A service object pair (SOP) class models a category of information object and a set of operation associated with this information object.
A DICOM object is a binary stream or a standalone file that encodes a DICOM SOP class instance according to the DICOM standard. A DICOM object can store different types of data, such as patient administration information, a waveform, an image, a slice of a 3D volume, a video segment, a diagnostic report, a graphic or text annotation. A DICOM object contains a number of standard attributes. It may optionally contain private attributes.
Transfer syntax designates a particular way of encoding a DICOM object into a binary stream. It also specifies how the data content should be compressed. Examples of DICOM compression codec include JPEG, JPEG-LS, JPEG2000 and MPEG2.
A DICOM image refers any DICOM object that can be decomposed into 2D pixel arrays. Examples include a video segment, volume scan, and a single frame dental image. A DICOM image is always a DICOM object, but the converse is not true.
A unique identifier (UID) is a 64 byte dot-concatenated numeric string (like an IP address). It is a DICOM data type that is based on ISO object identifier (OID). It uniquely identifies a DICOM object worldwide. It is commonly constructed with a root that uniquely identifies an organization producing DICOM objects and a suffix that uniquely identifies a DICOM object within the organization.
Some other definitions include:
A SQL object is the database object that encapsulates a DICOM object. The SQL object has public member methods that permit the query and processing of a DICOM object.
Metadata extraction is the process of extracting attributes from a DICOM object.
A parser extracts metadata from a DICOM object into an in-memory structure.
Metadata encoding is the process of encoding the extracted DICOM attributes into an DICOM metadata document.
A (XML) metadata encoder converts the in-memory structure of the extracted DICOM attributes into an XML document.
Schema validation is the process of using an XML schema definition to validate an XML document that is constrained by the schema. With schema validation, one may confirm the correctness of the data type, data format, and hierarchy. Schema validation is generally only applicable to XML documents and not to DICOM objects.
Standard conformance is the syntactical and semantic consistency of a DICOM object with respect to the DICOM standard. The default constraint definition documents can generally define constraints that enforce the DICOM standard conformance.
Application conformance is the semantic consistency of a DICOM object with respect to application specific conformance rules, which may be stronger or weaker than the DICOM standard. An administrator may modify the default constraint document to enforce a different set of conformance rules to better suit the application.
Conformance validation is the process of checking the semantic conformance of a DICOM object to the DICOM standard against constraint definition documents.
A (DICOM) metadata document is an XML document that encodes the attributes extracted from a DICOM object. Each DICOM object maps to one metadata document. We provide methods to build a metadata document from a DICOM object. A DICOM metadata document has two sections. One section is the named section, where elements are organized by a predefined hierarchy and each element is addressable by a fixed XPath. We refer to attributes in this section as named attributes. The other section is the unnamed section, where the rest of the extracted attributes are organized and listed by their value representation. Each attribute in this section can be addressed with an XPath query of the element tag (in the form of /DATA_TYPE(tag==‘HHHHHHHH’)). We refer to attributes in this section as unnamed attributes.
DICOM data type definition schema is an XML schema that defines the value representations (i.e. DICOM data types) given in the DICOM standard part 5. This data type definition schema is strongly coupled with DICOM parser. Any modification to this schema mandates data migration.
A metadata schema is the XML schema document that constrains the DICOM metadata document. This schema references the DICOM data type definition schema.
Standard data dictionary document is an XML document that lists the attributes defined by the DICOM standard. The DICOM standard data dictionary document is converted from the DICOM standard part 6. An administrator may update this document to reflect the most recent releases made by the DICOM standard committee.
Private data dictionary document lists private attributes. There are may be one or more private data dictionary documents. Each contains a set of private attribute definitions and its owning organization's UID. A private data dictionary document can be published by a third party. A database administrator may add new private data dictionary documents as they become available.
A (XML) mapping document is an XML document to define how each DICOM attribute should map to an element of the DICOM metadata document. The mapping document is used by the metadata encoder to produce a DICOM metadata document. Since the metadata document is constrained by the metadata schema, the mapping document must match the metadata schema and they can be derived from each other. We define a default mapping document that couples with the DICOM metadata schema. A database administrator may customize the mapping document and the metadata schema for each database instance.
Constraint definition documents are a set of XML documents that define groups of predicates to validate the conformance of a DICOM object or a DICOM metadata document. A constraint document should be based on the SOP class specification given in part 3 of the DICOM standard. It should specify attribute relationships and semantic constraint of an attribute that is not expressed by the DICOM metadata schema. An administrator may customize a constraint document to make it stronger, weaker or different from what have been defined by the DICOM standard.
Preference document specifies a set of the runtime preferences. We ship a default preference document. An administrator may update this document to change the run time behavior, such as changing the logging destination, turning on/off the logging of warning messages, and ignoring certain category of errors.
A configuration document is unique for each database instance and applicable to all DICOM objects stored in the database. Configuration documents are managed by the repository. Examples of configuration documents are data dictionary documents, the XML mapping document, constraint definition documents and a preference document.
A repository stores documents that are applicable to all SQL objects stored in a database instance. An administrator can access the repository and update the document stored in this repository. The changes made will affect the outcome of a method. Mapping document, data dictionary document and constraint document are examples of document stored in the repository. At runtime, a method will query the repository to get the latest copy of the document. For example, a database administrator updates an attribute definition in a data dictionary document and change its data type from DA (date) to DT (datatime). From there on, the parser will interpret this attribute as an instance of the DT (datatime) data type and the metadata encoder will encode this attribute as DT (datatime) in all future metadata documents.
DICOM volume scan is the set of images gathered in the single imaging operation. They can be stored as separate slices in multiple DICOM objects. Or they may be stored as a single DICOM multiframe object.